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Abstract 

The  military  has  invested  millions  of  dollar  in  collaborative  technologies  to  facilitate 
faster  planning,  better  situation  awareness  and  more  seamless  coordination  among 
dispersed  forces.  Despite  this  investment  there  has  been  little  reduction  in  the  size  of  fleet 
staffs  and  the  actual  impact  of  collaboration  on  the  conduct  of  military  operations  has 
proved  hard  to  measure.  There  are  a  number  of  problems  that  keep  the  military  from 
enjoying  the  full  benefit  from  the  collaborative  information  environment.  These  problems 
include  not  using  industry  standards  to  permit  interaction  among  vender  specific 
synchronous  collaborative  tools.  This  paper  will  focus  on  improving  collaboration  among 
operational  forces  by  using  established  standards  to  interconnect  collaboration  client 
endpoints.  These  endpoints  include  tool  suites  such  as  Lotus  SameTime,  DCTS  (Defense 
Collaborative  Tool  Suite),  H323  endpoints  (NetMeeting),  and  CISCO  IP  Phones.  Without 
standards  based  tool  suites  the  information  flow  within  the  military  will  continue  to  be 
hampered  by  vendor  specific  collaboration  stovepipes.  The  findings  in  this  paper  are 
based  on  observations  and  analysis  from  Fleet  Battle  Experiments  and  Limited  Objective 
Experiments  conducted  by  the  Navy  Warfare  Develop  Command  (NWDC). 

Introduction 

Collaborative  tools  can  be  divided  into  two  major  groupings,  asynchronous  and 
synchronous.  Asynchronous  tools  allow  collaboration  between  groups  where  participants 
are  not  aware  of  when  other  participants  will  be  engaged.  Email,  newsgroups  and  web 
portals  are  examples  of  asynchronous  collaborative  tools.  Synchronous  tools  allow 
collaboration  between  groups  by  participants  being  engaged  simultaneously.  .  Examples 
of  synchronous  tools  include  instant  messaging,  video  teleconferencing,  application 
sharing  (collaborative  document  development),  whiteboard,  and  text  based  chat. 

The  types  of  collaborative  tools  employed  will  largely  depend  on  the  mission  and 
infrastructure  available  to  the  organization.  If  the  mission  is  long  range  planning  among 
action  officers  much  of  the  interaction  will  involve  email,  web  portal  and  document 
management  tools.  If  the  mission  is  the  execution  of  plans,  collaborative  tools  that  permit 
voice  over  IP,  video  and  document  sharing  may  be  more  appropriate.  At  some  point  the 
long  range  planners  need  to  turn  the  plans  over  to  the  executers.  The  people  executing  the 
plan  will  have  questions  and  need  to  coordinate  and  collaborate  with  the  planners.  With 
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the  two  organizations  using  different  collaborative  tools  there  needs  to  be  common 
standards  to  allow  these  two  groups  to  share  information. 

In  the  area  of  asynchronous  collaboration  the  standards  are  well  understood  and  vendors 
adhere  to  those  standard.  This  allows  a  user  on  Lotus  Notes  to  send  an  email  to  a 
Microsoft  Outlook  user,  using  the  SMTP  standard.  Web  browsers  can  open  pages  built  on 
HTML  and  XML  standards  originating  from  a  multitude  of  source  types. 

Although  synchronous  collaboration  has  similar  standards  (SIP  Session  Initiation 
Protocol,  H.323,  T.120,  XMPP  (Extensible  Messaging  and  Presence  Protocol),  the 
standards  are  continually  being  defined.  Liberal  adherence  to  these  standards  can  cause 
interaction  between  the  tools  to  be  problematic.  Most  of  the  more  sophisticated  tools  like 
InfoWorkSpace  (IWS),  IP  Phone  systems,  Lotus  SameTime  and  First  Virtual’s  Click  to 
Meet  (CTM)  have  a  proprietary  collaboration  standard  as  well  as  the  ability  to 
communicate  using  accepted  H.323,  XMPP,  and/or  SIP  standards.  Even  with  these 
established  standards  interoperability  is  not  a  given.  Until  synchronous  collaboration 
standards  are  followed  and  implemented,  like  SMTP,  interoperability  will  be  limited  to 
the  venders'  implementation  of  standards.  The  implementation  of  standards  in  many 
cases  is  inadequate  for  the  required  collaboration  tools  and  services  now  being  used. 

The  search  for  a  single  tool  that  fulfills  all  collaboration  requirements  has  led  the  military 
to  jump  at  each  new  technology  in  the  hope  of  finally  finding  the  perfect  collaboration 
tools.  The  problem  is  exasperated  by  the  limited  bandwidth  available  to  afloat  and 
forward  deployed  forces  and  different  functions  each  groups  needs  the  tools  to  perform. 
There  are  many  reasons  why  moving  towards  a  Department  of  Defense  (DOD)  wide 
accepted  standard  would  be  beneficial.  These  reasons  include; 

>  Preserve  the  investment  services  have  already  made  in  collaborative  technology 

>  Allow  staff  members  to  join  conference  on  different  collaboration  servers  through 
a  single  endpoint  client 

>  Allow  services  to  use  specific  endpoint  tools  optimized  to  operate  in  a  limited 
bandwidth  environment 

>  Allow  services  to  use  tools  with  special  functionality  not  needed  by  other 
services.  Allow  the  employment  of  client  tools  with  a  simplified  interface  for 
infrequent  users. 

>  Allow  endpoint  to  endpoint  awareness  and  collaboration 

This  paper  will  focus  on  using  standards  to  allow  the  interconnection  of  collaborative 
endpoints  (IP  Phones,  Room  VTC,  Desktop  Collaboration  tools)  from  different  venders 
to  address  the  six  reasons  listed  above.  Desktop  collaboration  tools  are  those  that  provide 
team  rooms,  applications  sharing,  audio/  video  conferencing  and  whiteboard.  Using 
standards  allows  sharing  of  information  and  services  between  vendor  tool  sets  and  allows 
each  functional  group  (planning,  logistics,  operations)  to  use  tools  best  suited  for  their 
purposes  and  still  join  planning  sessions  and  exchange  information  with  other 
participants. 
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Experiment  Design 

Synchronous  and  Asynchronous  collaboration  among  operational  forces  has  been  a 
central  focus  of  Fleet  Battle  Experiments  (FBEs)  and  Limited  Objective  Experiments 
(LOEs)  at  the  NWDC  since  its  inception  in  1998.  During  these  experiments  an 
increasingly  complex  suite  of  collaborative  tools  have  been  introduced  to  fleet  users  and 
allowed  the  tools  to  play  a  more  critical  role  in  staff  operations.  During  early  FBEs  IRC 
(Internet  Relay  Chat)  was  used  as  a  better  way  to  coordinate  operations  among  dispersed 
forces  and  a  web  site  was  stood  up  to  allow  information  producers  to  quickly  post  daily 
products.  Later  experiments  focused  more  on  email  architectures,  web  portals,  document 
management,  synchronous  data  collaboration,  and  voice  over  IP.  During  the  most  recent 
experiments,  Millennium  Challenge  02,  the  Split  Staff  LOE  and  the  Joint  Forces 
Command  (JFCOM)  Collaborative  Information  Environment  (CIE)  LOE,  the 
collaboration  experimentation  focused  on  the  employment  and  integration  of 
synchronous  collaborative  tool  suits  like  IWS  and  DCTS.  These  tools  provided 
significant  functionality  like  voice  over  IP,  video,  applications  sharing,  whiteboards,  and 
shared  views.  These  experiments  used  collaborative  tools  to  support,  for  example, 
planning  and  execution  at  the  Joint  Forces  Maritime  Component  Commander  (JFMCC) 
level  and  the  coordination  between  the  JFMCC  and  the  Joint  Task  Force  (JTF) 
commander.  Collaborative  interoperability  work  was  accomplished  allowing  different 
collaborative  devices  to  pass  information  using  established  standards,  during  the  Split 
Staff  LOE  and  the  CIE  LOE. 

Even  though  the  experimentation  focus  was  on  the  operational  processes  there  was  much 
useful  information  gained  about  the  problems  associated  with  the  employment  of 
collaborative  tools.  The  Information  and  Knowledge  Assurance  (IKA)  initiatives,  within 
the  larger  experiment,  focused  on  the  Collaborative  Information  Environment.  The 
finding  from  collaborative  tool  experimentation  made  the  importance  of  implementing  a 
standards  based  collaborative  environment  very  clear.  Experimentation  highlighted  the 
technical  issues  associated  with  allowing  different  collaborative  tools  to  exchanged 
information  with  dissimilar  endpoint  devices.  Specifically  experimentation  focused  on 
allowing  desktop  collaborative  tools,  IP  phones  and  room  VTC  to  join  into  a  conferences 
hosted  on  DCTS's  First  Virtual  Conference  Server  MCU  (Multi-point  Control  Unit)  and 
share  resources.  The  resources  shared  were  dependant  on  the  client  but  generally 
included  audio  and  video. 

Tool  and  network  analysis  is  difficult  on  operational  networks  because  there  are  too 
many  uncontrolled  variables.  Much  of  this  analysis  is  subjective  because  the  evaluation 
involves  user’s  opinions  of  how  well  the  tool  supported  the  mission.  Surrogate  networks 
emulating  operational  networks  without  all  the  wildcards  have  been  constructed  in  order 
to  provide  some  quantitative  analysis.  During  the  CIE  LOE  NetFlow  monitoring 
equipment  was  set  up  to  allow  detailed  recording  of  each  tool's  bandwidth  consumption. 
While  this  information  was  not  critical  to  understanding  standards  based  collaboration  it 
did  help  in  understand  which  collaborative  client  operated  most  efficiently  in  a  bandwidth 
constrained  environment. 

The  collaborative  tool  experimentation  took  place  in  three  environments.  Some 
experimentation  was  conducted  on  fleet  secret  network  (Secret  Internet  Protocol  Router 
Network  SIPRNET),  other  tests  occurred  in  enclaves  with  access  to  SIPRNET  and  other 
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testing  was  done  in  the  lab  on  closed  networks.  The  focus  of  NWDC’s  experimentation  is 
on  the  fleet  and  the  application  of  new  concepts,  procedures  and  technologies  to  fleet 
operations.  Therefore,  whenever  possible  NWDC  seeks  to  operate  on  actual  fleet 
communications  networks.  When  working  in  the  lab  environment  satellite  emulators 
were  used  to  impair  bandwidth  by  introducing  bottlenecks,  latency,  and  an  error  rate  that 
could  be  expected  in  the  fleet. 

Findings/  Discussion 

The  problem  of  interoperability  among  collaboration  tools  has  become  more  acute 
recently  as  the  deployment  of  synchronous  collaborative  tools  has  dramatically  increased. 
Each  service,  and  some  cases  specialized  components  of  services,  have  purchased 
different  tools  and  when  these  forces  come  together  to  conduct  Joint  Task  Force 
Operations  the  results  are  islands  of  collaboration  that  don’t  interact  effectively.  Despite 
much  discussion  on  a  common  collaboration  standard,  no  agreement  on  a  standard,  that 
will  allow  interoperability  at  the  client  level,  has  been  reached.  The  inability  to  settle  on  a 
single  collaborative  tool  or  a  single  standard  has  resulted  in  stovepipes  of  collaboration 
that  hamper  coordination  between  and  within  services.  The  reasons  for  the  multiple 
collaborative  tools  include: 

•  Services  have  already  invested  in  tools  and  their  limited  financial  resources  will 
not  allow  complete  replacement  of  existing  systems. 

•  Current  software  provides  unique  functionality  not  available  in  other  collaborative 
tools. 

•  Current  collaborative  system  works  in  a  bandwidth  constrained  environment. 

•  Training  requirements  for  both  operators  and  technicians  make  changing  to  a  new 
collaborative  tools  suite  difficult. 

•  New  tools  are  released  so  frequently  that  any  product  chosen  might  be  out  dated 
within  a  year. 

•  Operational  staffs  have  little  control  over  the  collaborative  software  they  are 
expected  to  use. 

•  Different  governing  organizations  are  dictating  different  products  and  no 
organization  is  providing  all  the  resources  to  purchase,  install,  and  train  users  on 
the  new  tools  being  mandated. 

•  Some  of  the  tools  being  mandated  have  antiqued  user  interfaces  and  limited 
functionality.  Users  are  frustrated  by  the  disparity  between  the  tools  available 
commercially  and  what  is  approved  for  military  use. 

•  Early  experiences  with  robust  collaboration  suites  were  disappointing  and  staffs 
are  reluctant  to  repeat  the  experience. 

For  the  reasons  listed  above  its  unlikely  the  military  will  be  able  to  agree  on  and  purchase 
a  single  vendor’s  tools.  Linking  together  disparate  collaborative  tools  through  accepted 
standards  provides  the  most  viable  solution  to  the  growing  numbers  of  collaborative  tool 
stovepipes.  If  all  the  tools,  being  installed  in  the  fleet,  adhered  to  accepted  standards  each 
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service  or  military  unit  could  continue  to  use  the  collaborative  tools  they  were  trained  on 
and  still  interact  with  other  units  using  different  tools. 

During  laboratory  testing,  for  the  C2F  Split  Staff  LOE  and  the  CIE  LOE,  NWDC 
experimented  with  four  tool  suites.  These  suites  are  IWS,  DCTS,  Lotus  SameTime,  and 
FVC  Click  to  Meet  Express. 

Synchronous  collaborative  tools  employ  two  methods  of  transferring  UDP  (User 
Datagram  Protocol)  traffic  voice  and  video).  These  two  transmission  methods  are  unicast 
and  multicast.  These  two  methods  can  be  combined  to  produce  three  options  for  voice, 
video  and  data  transmission,  which  are  unicast,  multicast  and  IP  multicast  between 
MCUs.  Multicast  has  some  significant  advantages  in  term  of  bandwidth  efficiency  over 
unicast  however  multicast  is  not  used  in  fleet  communications  today  because  of  the  need 
for  special  network  routers  and  the  danger  of  multicast  traffic  flooding  the  network. 
There  are  two  multicast  modes  sparse  and  dense.  Dense  mode  will  broadcast  the  packets 
to  all  multicast  enabled  routers  while  sparse  mode  will  only  transmit  packets  to  where 
there  are  requesting  endpoints.  With  unicast  there  are  n  transmissions  to  n  clients,  i.e.  for 
30  clients  30  transmission  streams  are  needed.  See  Figure  1.  With  multicast  there  is  1 
transmission  for  n  clients  i.e.  1  transmission  for  30  clients  See  Figure  2.  The  network 
routers  in  multicast  transmit  the  packets  to  what  is  called  a  multicast  group.  The  clients 
interested  in  the  packets  would  then  subscribe  to  the  group,  similar  to  how  a  radio  and 
TV  stations  work.  Multicast  can  be  applied  to  a  multi  MCU  architecture,  where  one 
transmission  could  be  transmitted  to  multiple  MCUs. 


With  the  H.323  standard  there  are  four  different  functional  units  that  comprise  a  H.323 
network.  These  units  are  Gatekeepers,  MCU,  Gateways  and  endpoints.  Gatekeepers 
ensure  calls  are  routed  across  the  network;  they  control  end  point  access  to  network 
resources,  monitor  service  usage,  and  perform  control  and  management  functions 
necessary  for  the  integrity  of  the  system.  The  MCU  supports  multi-party  conferences 
between  multiple  locations  in  both  a  centralized  and  decentralized  MCU  architecture.  The 
gateways  are  used  to  translate  between  protocols  and  for  connecting  IP  based  voice  and 
video  and  the  Public  Switched  Networks  (PSTN).  Finally  the  endpoints  are  end  user 
devices  such  as  the  NetMeeting,  Vigo,  Tandberg  Room  VTC,  and  IP  telephones. 

Different  vendors  commonly  produced  these  devises,  which  adds  to  the  complexity.  In  a 
standards  based  collaborative  environment,  where  an  ad  hoc  team  of  forces  has  been 
brought  together  to  support  a  JTF,  it  is  very  likely  that  all  the  pieces  of  the  H.323  network 
will  be  from  different  vendors.  Having  multiple  MCUs  and  endpoints  from  different 
vendors  collaborating  across  a  standard’s  based  network  is  very  difficult  but  absolutely 
needed  based  on  the  diversity  across  the  DOD. 
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The  other  standard  often  referred  to  is  T.120.  T.120  architecture  is  actually  a  family  of 
protocols  the  cover  the  multi-user  sharing  of  data.  The  T.122,  T.123,  T.124  and  T.125 
make  up  the  networking  level  of  the  T.120  standard.  The  applications  standards  are 
T.125,  T.127  and  T.128.  The  T.125  is  the  multi-user  whiteboard  function.  The  T.127  is 
the  file  transfer  standard  and  T.128  is  the  program  sharing  standard.  Data  interoperability 
between  T.120  clients  has  not  yet  been  the  focus  of  extensive  testing.  There  was  little 
success  with  the  testing  performed. 

During  laboratory  events  and  LOEs  the  tools  interoperability  was  tested  based  on  the 
H.323  and  T.120  standards.  The  tests  can  be  grouped  into  3  major  categories;  endpoint  to 
endpoint,  endpoint  to  MCU,  MCU  to  MCU.  In  this  paper  the  term  MCU  is  used  to  refer 
to  both  MCUs  and  conferencing  servers  since  most  collaboration  suites  contain  much 
more  functionality  than  is  required  by  the  H.323  MCU  standard.  Despite  the  multitude  of 
capabilities  in  a  collaboration  suite,  the  initial  testing  focused  on  sharing  audio  and  video 
between  collaboration  suites  and  endpoints.  Devices  used  during  the  tests  were: 

>  Endpoints:  NetMeeting,  Vigo,  Cisco  IP  phone,  Tandberg  8080,  Nortel  IP  phone; 
Collaboration  Suites:  InfoWorkSpace  (IWS)  2.5.1,  Lotus  SameTime  2.5;  First 
Virtual  Click  to  Meet  Express  2.0; 

>  MCUs:  Cisco  IP/VC  3540,  FV  Conference  Server  6.0  and  7.0; 

>  Gateways:  Cisco  Call  Manager  3.3.3,  Lotus  Sametime  2.5,  FV  Conference  Server 
6.0  and  7.0; 

>  Gatekeepers:  Cisco  MCM  (Multi  Media  Conference  Manager),  FV  Conference 
Server  6.0  and  7.0,  Microsoft  ISA. 
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Figure  3  Multiple  Endpoint,  MCU,  and  Gatekeeper  Architecture 

The  specific  standards  based  collaboration  tests  conducted  were: 

1.  Endpoint  to  Endpoint:  Several  lab  tests  were  conducted  verifying  connectivity 
between  H.323  endpoints.  A  Cisco  gatekeeper  provided  the  dial  plan.  All  endpoints 
were  able  to  conduct  audio  sessions  and  all  video  enabled  endpoints  were  able  to 
receive  and  transmit  video.  The  H.323  end  points  tested  included  NetMeeting,  VIGO 
VTC  and  Tandburg  VTC.  IWS,  Click  to  Meet,  and  SameTime  clients  are  not  H.323 
endpoints  thus  they  can  only  participate  in  collaborative  sessions  with  their  respective 
servers. 

2.  Endpoint  to  MCU/Conference  Server:  H.323  MCUs  are  designed  to  work  with  all 
H.323  endpoints.  Conference  Servers  are  primarily  designed  to  interact  with  their 
clients  first  and  then  if  a  H.323  gateway  is  provided  a  H.323  endpoint  may  participate 
in  a  conference.  The  following  tests  determined  the  level  of  interoperability  of 
conference  servers  with  other  H.323  endpoints. 

a.  Cisco  3540  MCU:  The  Cisco  MCU  successfully  conducted  audio  and  video 
session  with  all  H.323  endpoints.  The  Cisco  gatekeeper  was  used  to  provide  a 
dial  plan  for  all  H.323  endpoints  to  enter  conference.  Data  collaboration 
(T.120)  was  not  available  for  these  tests  because  the  Cisco  T.120  module  was 
not  available. 
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b.  FV  Conference  Server  7.0:  The  FV  conference  server  successfully 
conducted  audio,  video,  and  data  (T.120)  sessions  with  capable  H.323 
endpoints.  The  CTM  (Click  to  Meet)  express  client  uses  an  http  control 
capability  for  presentations.  This  feature  was  not  available  to  endpoints 
because  it  is  not  part  of  the  T.  120  protocol.  All  endpoints  registered  to  the  FV 
Conference  Server’s  gatekeeper. 

c.  Lotus  SameTime  2.5:  The  SameTime  H.323  gateway  did  not  work 
consistently  with  all  endpoints.  When  the  SameTime  server  was  registered  to 
the  Cisco  gatekeeper  Cisco  IP  phone  establishing  a  session  with  a  SameTime 
conference  was  sporadic.  NetMeeting  would  establish  connection  and  then 
drop  out.  Although  SameTime  has  an  H.323  gateway  it  is  not  a  true  MCU. 
This  may  have  played  a  part  with  the  endpoint  connectivity  issues.  In  order  to 
establish  a  more  detail  case  as  to  why  the  endpoints  didn’t  work,  vendor 
support  will  be  needed. 

d.  InfoWorkSpace:  Out  of  all  the  collaboration  suites  tested  IWS  was  the  only 
one  without  a  H.323  gateway.  Without  a  gateway  the  only  client  IWS  can 
work  with  is  its  own  client 

3.  MCU/Conference  Server  to  MCU/Conference  Server: 

a.  Cisco  MCU  to  FV  Conference  Server  7.0:  The  two  MCUs  were  connected, 
but  they  were  not  truly  cascaded.  They  were  able  to  share  audio  and  video. 
The  connection  was  established  by  inviting  the  FV  conference  from  the  Cisco 
MCU.  T.120  did  not  work  because  it  was  not  part  of  the  Cisco  MCU. 

b.  Cisco  MCU  to  Lotus  SameTime  2.5:  The  two  MCUs  were  connected,  but 
they  were  not  truly  cascaded.  They  were  able  to  share  audio  but  the  video 
worked  only  in  one  direction.  The  connection  was  established  by  inviting  the 
SameTime  conference  from  the  Cisco  MCU.  T.120  did  not  work  because  it 
was  not  part  of  the  Cisco  MCU. 

c.  FV  Conference  Server  7.0  to  Lotus  SameTime  2.5:  The  collaborative  suites 
used  were  SameTime  2.5  and  CTM  Express  2.0  pointing  to  a  FV  Conference 
Server.  A  CISCO  MCU  was  used  to  invite  a  conference  on  the  Same  Time 
Server  and  a  conference  on  FV  conferencing  server  into  a  conference  on  the 
CISCO  MCU.  With  this  configuration  the  two  desktop  collaborative  tools 
were  able  to  conduct  audio  collaboration.  Video  was  attempted  but  was 
unidirectional.  T.120  was  not  possible  because  it  was  not  part  of  the  Cisco 
MCU. 

The  primary  findings  are  H.323  audio  worked  in  most  cases  but  video  was  far  more 
problematic.  The  T.120  only  worked  from  MCU  to  endpoint.  Therefore  even  though 
NetMeeting,  FV  Click  to  Meet  and  Lotus  SameTime  are  all  H.323  and  T.120  compatible 
only  limited  audio  interoperability  was  achieved.  The  T.120  module  for  the  Cisco  MCU 
may  solve  these  problems.  More  effort  is  needed  to  get  data  collaboration  working 
between  MCUs  or  collaboration  suites. 

The  standards  issue  is  further  complicated  by  discussions  over  what  standard  to  adopt. 
With  voice  and  video  over  IP  the  discussion  has  resolved  around  whether  to  stay  with  the 
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International  Telecommunications  Union  (ITU)  blessed  H.323  standard  or  adopt  new 
standards  SIP  and  XMPP,  which  is  backed  by  a  growing  number  of  equipment  and 
service  providers.  While  it  appears  H.323  still  has  favor  in  the  DOD,  there  is  no 
guarantee  that  H.323  will  still  be  the  standard  of  choice  for  packet  based  multimedia 
communications  in  the  future.  The  DISA  sponsored  Collaboration  Interoperability 
Working  Group  (CIWG)  meets  on  a  regular  basis  to  discuss  DOD  collaboration.  XMPP 
and  SIP  have  been  significant  topics  of  conversation  of  late.  Because  of  XMPP’ s 
extensible  nature  VoIP  and  whiteboard  capabilities  can  be  added  to  its  text  messaging 
and  presence  protocols.  With  the  cores  set  of  capabilities  available  in  XMPP  it  becomes 
a  logical  choice  for  DOD  collaboration.  Even  if  H.323  does  remain  the  standard  there  are 
new  versions  of  the  protocol  released  on  a  regular  bases  and  application  must  be 
continually  updated  to  conform  to  the  latest  H.323  version.  These  updates  are  necessary 
to  integrate  new  features  and  to  eliminate  security  holes  in  previously  released  standards. 
While  these  continual  updates  are  expensive  for  developers  and  inconvenient  for  users 
they  are  necessary  and  there  are  real  benefits  in  having  tools  conform  to  the  latest 
standards.  These  standards  are  often  complex  and  leave  a  great  deal  of  room  for 
interpretation.  With  the  H.323  standard  alone  version  4  is  the  latest  release  yet  most  tools 
in  use  comply  with  version  2  or  3. 

Vendors  build  tools  that  will  provide  the  greatest  functionality  to  their  users.  Exact 
adherence  to  standards  is  not  a  problem  users  are  likely  to  notice  when  viewing  a  tool’s 
functionality.  More  importantly  vendors  make  money  by  selling  more  licenses  not  by 
protecting  the  user’s  current  investment.  In  some  cases  the  proprietary  features  a 
collaborative  tool  provides  are  the  most  capable  component  of  the  tool  suite.  Therefore 
users  may  have  to  accept  less  functionality  in  order  to  get  fuller  compliance  with 
standards.  The  buyer  will  need  to  enforce  interoperability  standards  by  only  buying 
software  that  is  truly  interoperable. 

The  term  interoperability  has  been  used  liberally  to  describe  the  ability  to  exchange 
information  between  collaborative  systems.  The  problem  is  collaborative  tool  suites  like 
DCTS  and  Lotus  SameTime  are  complicated  and  contain  multiple  components.  Even 
though  both  tools  are  built  to  H.323  and  T.120  standards  the  two  tool  suites  are  only  able 
to  exchange  audio  and  that  exchange  happens  through  the  CISCO  MCU.  The 
interoperability  problem  gets  even  more  difficult  with  tools  like  IWS  that  are  built  to 
proprietary  standards.  With  tools  built  to  proprietary  standards  interoperability  only 
happens  when  translators  (gateways)  are  installed  between  the  two  systems.  Some 
manufactures  like  CISCO  that  use  proprietary  standards,  include  translators  in  their 
gateways  to  allow  interaction  with  other  widely  accepted  protocols.  For  tools  like  IWS 
with  limited  installation  base  the  translation  tools  do  not  exist. 

Within  the  military,  organizations  exist  to  test  collaborative  tools  to  assure  conformance 
to  accepted  interoperability  standards.  The  Joint  Interoperability  Test  Center  (JITC)  is 
one  such  organization.  JITC  has  defined  three  levels  of  certification:  system,  component, 
and  enhancement.  The  enhancement  certification  has  two  major  criteria,  presence 
awareness  and  the  ability  of  the  clients  to  coexistence  on  a  common  workstation.  Because 
JITC  has  defined  three  levels  of  certification,  tools  certified  as  enhancements  (IWS)  are 
not  100%  interoperable.  The  IWS  client  cannot  participate  in  audio,  video,  or  data 
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collaboration  with  out  launching  a  certified  component  such  as  NetMeeting.  This  presents 
some  confusion  as  to  the  meaning  of  being  JITC  interoperable  certified. 

In  industry  many  products  advertise  compliance  with  standards  but  in  reality  these 
products  are  only  partially  compliant.  That  means  only  a  few  features  of  the  many  offered 
by  the  vendor  are  actually  built  to  be  compliant  with  H.323  or  T.120  standards.  With  the 
loose  interpretation  of  the  standards  even  if  two  vendors  built  a  tool  function  to  be 
compliant  with  standards  it  is  still  possible  the  two  tools  will  not  interoperate  fully.  Many 
synchronous  collaboration  vendors  make  their  tools  proprietary  in  order  to  protect  their 
investments. 

The  ability  of  tools  to  interoperate  must  be  addressed  at  several  layers  to  provide  the 
functionality  users  need.  These  layers  include: 

•  Authentication  of  users  entering  the  session 

•  Dialing  plan,  especially  in  a  multiple  MCU  environment  (ability  to  establish 
sessions  with  remote  users) 

•  Awareness  of  connected  users  and  virtual  locations 

•  Support  multiple  Audio  and  Video  codecs  and  protocols 

•  File  transfer 

•  Text  chat 

The  issue  of  the  additional  complexity  associated  with  interconnecting  collaborative  tools 
based  on  standards  must  be  addressed.  The  technician  onboard  a  ship  may  have  problems 
making  single  vendor  collaborative  tools  work  let  alone  interconnecting  tools  from 
different  vendors.  For  example,  with  IWS  there  are  no  decisions  required  in  terms  of 
audio  or  video  codex  because  the  tool  does  not  support  multiple  codex  (coder  decoder).  If 
however  FV  Click  to  Meet  is  being  brought  into  a  SameTime  environment,  issues  of 
audio  and  video  codecs  must  be  considered.  Issues  of  which  gatekeeper  to  use,  what 
addressing  scheme  will  be  used  and  gateways  must  be  considered  in  a  multiple  vendor 
environment  as  well. 

Summary 

Standards  based  interoperability  of  synchronous  collaborative  tools  presents  the  most 
logic  path  forward  for  breaking  down  the  stovepipes  of  collaborative  tools  that  now  exist. 
Because  of  cost,  training  and  bandwidth  issues  completely  dropping  the  currently  used 
tools  and  switching  to  a  single  Department  of  Defense  wide  tool  is  not  a  viable  option. 
During  recent  laboratory  and  fleet  experimentation  the  feasibility  of  connecting 
collaborative  tools  based  on  industry  standards  was  proven  viable.  There  are  numerous 
standards  adherence  issues  that  make  the  integration  of  different  vendor’s  collaborative 
tools  difficult.  The  complexity  of  this  integration  issue  is  further  complicated  by  the 
steady  introduction  of  new  standards.  The  collaborative  tools  in  use  today  are 
complicated  products  with  much  functionality.  In  some  cases  each  function  in  the  tool  set 
is  support  by  a  different  standard.  So  far  audio  collaboration  has  been  the  most  integrated 
capabilities.  The  data  collaboration  has  proved  to  be  the  most  difficult. 
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Road  Ahead 

The  desired  end  state,  for  standards  based  interoperability  among  synchronous 
collaborative  tools,  is  comparable  to  the  interoperability  email  clients  enjoy  using  the 
SMTP  standard.  Before  email  was  standardized  interoperability  between  email  systems 
was  difficult.  Email  interoperability  is  no  longer  a  consideration.  Client  interoperability 
problems  were  solved  by  agreeing  to  client  to  server  standards  (POP3,  IMAP)  and  server 
to  server  standards  (SMTP).  Developing  agreed  upon  standards  for  synchronous 
collaborative  tools  has  been  hard  because  the  functionality  of  these  tools  keeps  expanding 
and  the  tools  are  much  more  complex  than  email.  The  foundation,  for  these  future 
standards,  exist  in  the  synchronous  standards  (H.323,  T.120,  XMPP,  SIP)  being  used 
today. 

Basic  synchronous  collaboration  capabilities  should  include:  VoIP,  text  chat,  white 
board,  application  share,  http  control,  and  user  awareness.  Every  client  should  contain 
these  basic  capabilities.  Collaboration  suites  could  then  add  any  additional  functionality 
to  their  tool  set  like  Microsoft  Exchange  has  added  calendaring  and  other  feature  above 
and  beyond  the  standard  email  functions.  If  all  tools  adhere  to  these  standards  it  would 
be  possible  to  find  and  initiate  collaborative  sessions  with  anyone  on  DOD  networks  that 
has  a  client  conforming  to  these  basic  capabilities. 
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Experiment  Background 


•  Distributed  C2  Initiative  Areas 

-  Collaborative  Information  Environment  (CIE) 

-  Agent  Based  Computing  (ABC) 

-  Information  Management  (IM) 

-  Cross  Domain  Solutions  (CDS) 

-  Advanced  Networking 

•  Events  Completed 

-  Split  Staff  Experiment,  MNME  03  (C2F,  Norfolk) 

-  JFCOM  CIE  LOE  (NWDC  Lab) 

-  Multiple  Secure  Level  Exploration  (NWDC  Lab) 
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Abstract 


•  Several  significant  problems  prevent  the 
military  from  enjoying  the  full  benefit  of 
collaborative  tools.  These  problems 
include  poorly  defined  standards  and  a 
lack  of  adherence.  These  problems  are 
not  insurmountable.  This  paper 
addresses  these  problems  and  describe 
some  solutions  tested  during  limited 
objective  experiments. 
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Background 


•  Synchronous  focus  verses 
asynchronous 

•  Military  planning  focus  verse 
execution 

•  Overhead  associated  with  toolset 

•  Operational  focus  verses  tactical  or 
strategic 

•  Multiple  tool  integration  verses 
single  tool 
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Experiment  Design 


•  NWDC  conducts  experimentation  at 
the  Operational  level 

-Technical  exploration  secondary 

•  Collaborative  Tools  a  focus  in  many 
Fleet  Battle  Experiments 

-  Systems  examined  in  several  venues 

•  Experiment  series  tested  an 
increasingly  complex  suite  of  tools 
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Issues  preventing  agreement  on 
single  collaborative  system 


-Sunk  cost 

-Unique  functionality 

-Bandwidth  Issues 

-Training  on  yet  another  system 

-Each  tools  has  its  own  supporters 

-Interface  preference 

-Prior  experience  (Negative) 
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Benefits  of  Standards  Based 
Interoperability 


Reduced  Stovepipes 

Reduced  training 

Reduced  software  installation 

Users  focused  on  subject  matter  not 
learning  new  tools 
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Issues  preventing  Standards 
Based  Interoperability 


•  Poorly  defined  standards 

•  Vendors  not  fully  implementing 
standards 

•  Frequently  updated  standards 

•  Potential  loss  of  functionality 

•  Complexity  of  solution 

•  Vendor  not  motivated  to  support 
interoperability 
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Standards 


•  H.323 

•  T.120 

-Network  T.122,  T.123,  T.124 
-Application  T.125.  T.127,  T.128 

•  SIP  (Session  Initiation  Protocol) 

•  SIMPLE  (SIP  Instant  Messaging  and 
Presence  Leveraging  Extensions) 

•  XMPP  (Extensible  Messaging  and 
Presence  Protocol) 

•  Proprietary  Protocols 


H.323  Terminology 


End  Points 

-  User  Interface  (NetMeeting,  VTC) 

MCUs 

-  Support  multiple  party  conferences 

Gateways 

-Translate  between  protocols,  and  IP  to 
Public  Switched  Network 

Gatekeepers 

-  Route  calls,  control  access,  monitor 
usage,  management  functions 
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Functionality  Sought 


•  Voice  over  IP  (VoIP) 

•  Text  Chat 

•  Whiteboard 

•  Application  Sharing 

•  HTTP  Control 

•  User  awareness 

•  Group  Work  space 

•  Video 

•  File  Transfer 

•  Dialing  Plan 
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Testing  Conducted 


•  End  Point  to  End  Point 

-  Fully  H.323  compliant  NetMeeting, 
VIGO,  Tandberg 

•  End  Point  to  MCU /  Server 

-  Click  to  Meet  to  First  Virtual  Server 
(FVS),  NetMeeting  to  FVS,  CISCO  IP 
Phone  to  FVS 

•  Server  to  Server/  MCU 

-  SameTime  to  FVS 

-  SameTime  and  FVS  to  CISCO  MCU 
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Interoperability  Options 


•  Any  endpoint  can  talk  to  any 
MCU  /  Server 

•  Endpoints  into  specific  servers 
with  servers  talking  to  other 
severs 

•  Endpoints  into  specific  servers 
with  servers  all  talking  to  third 
party  server  which  bridges 
between  servers 
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Sample  Multi-Endpoint  and  Multi-Server 

Architecture 


-  Audio/Video  Streams 

RAS  (Registration,  Admission,  and  Status) 
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Interoperability  Bottom  line 


•  Audio  between  different  end  points  using 
common  MCU  worked.  Used  IP  phones, 
VTC,  and  synchronous  collaborative  tool 
suites  with  First  Virtual  Server. 

•  Audio  between  servers  accomplished  only 
through  CISCO  MCU  bridge 

•  Limited  testing  done  with  video  between 
server.  One  way  video  only  demonstrated 

•  T.120  interoperability 

-  Different  end  point  through  common  server 
worked 

-  Interoperability  a  problem  between  servers; 
CISCO  bridge  did  not  support 
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Road  Ahead 


•  Continue  work  on  new  protocols  to 
understand  benefits  and  costs 

•  Continue  experimentation  in  bandwidth 
efficient  topologies/  tools. 

•  Explore  information  management 
techniques  for  afloat  environment 

•  Continue  close  coordination  with  JFCOM 

•  Standards  base  CIE  with  Multi-national 
security  domains 

•  Support  future  Fleet  operational 
experimentation 
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Conclusion 


The  standards  exist  to  connect 
multiple  collaborative  tools  into  a 
single  conference  sharing  voice, 
video  and  data.  Employing  and 
interconnecting  standards  based 
tools  is  not  easy  but  the  benefit  out 
weigh  the  costs.  Venders  must  be 
pushed  to  make  tool  fully  adhere  to 
agreed  upon  standards. 
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